Norma para la gestión de datos

Ámbito de aplicación de la norma

Por el momento, esta norma no es de obligado cumplimiento, sino que define buenas prácticas en el ámbito de gobierno y analítica del dato.

Esta norma es de aplicación tanto para nuevos desarrollos como mantenimientos que incluyan la gestión integrada de datos, abarcando todo el ciclo de vida de la información, independientemente de la infraestructura en la que se despliegue. 

Las directrices que contiene la norma son independientes de la pila tecnológica utilizada para el desarrollo de la solución software. Los objetivos y características de la arquitectura no están vinculadas a la plataforma de publicación.

Por tanto, al implementar una solución de gestión de datos en una infraestructura específica, deben tenerse en cuenta:

• Las directrices y estándares establecidos en esta norma.
• Otras normas o requisitos específicos aplicables a la infraestructura o entorno tecnológico utilizado.

Puedes conocer en esta sección  cómo se marca la obligatoriedad de cumplimiento de las directrices que componen la norma.

Diseño

DIR_01 Modelo de datos

OBLIGATORIO El modelo de datos se diseñará en tres capas: modelo conceptual, modelo lógico y modelo físico.

• Conceptual: capa que indicará el modelo de entidades y relaciones. A menudo son utilizados los modelos entidad-relación y el modelo relacional para plasmar el mapa de entidades y la relación entre las mismas.
• Lógico: capa que definirá las estructuras de los elementos y sus relaciones. Profundiza más en la relación de atributos de las entidades, así como las claves primarias y ajenas, especificando su tipo (una-a-una, una-a-muchas, muchas-a-muchas).
• Físico: capa que describirá la parte física del modelo, entendiéndose como tal los las tablas que plasman las entidades, los esquemas que contienen las tablas, las columnas que plasman los atributos y las relaciones entre dichas tablas.

DIR_02 Escalabilidad

OBLIGATORIO El diseño de la plataforma que conforma la arquitectura de datos será escalable para no convertirse en un factor limitante del rendimiento o del crecimiento del sistema.

En este punto, resulta especialmente interesante el uso de la nube, debido a la facilidad para añadir o liberar recursos necesarios según resulte necesario en un momento dado.

• Almacenamiento de ficheros: El diseño de la arquitectura de datos dispondrá de escalabilidad del almacenamiento en el Data Lake, con el fin de evitar el agotamiento del espacio disponible y prevenir bloqueos en las aplicaciones que transfieren datos desde las fuentes de origen. El almacenamiento en la nube permite aumentar el espacio disponible automáticamente según unas reglas definidas para impedir ocasionar un bloqueo al sistema.
• Almacenamiento de base de datos: el diseño de la arquitectura de datos tendrá la escalabilidad necesaria en el espacio disponible para no bloquear procesos que necesitan realizar inserciones en las bases de datos. Los servicios gestionados de base de datos de los proveedores de cloud escalan el espacio disponible para evitar que se produzca un bloqueo en la plataforma.
• Procesamiento: el diseño de la arquitectura de datos contemplará la escalabilidad necesaria en el procesamiento para evitar limitaciones de rendimiento ante un pico en la necesidad de procesamiento de la plataforma. Resulta especialmente útil el escalado horizontal, que consiste en añadir nodos adicionales de procesamiento para repartir más la carga y aumentar la capacidad total. En el bagaje de los servicios de los proveedores de cloud computing, existen mecanismos para crear o eliminar nodos adicionales de procesamiento, así como de balanceadores que repartan la carga entre los distintos nodos. En el ecosistema de BigData, basado en procesamiento distribuido, esto ayuda a evitar bloqueos causados por alcanzar el tope de la capacidad de procesamiento del sistema y que originan pérdidas de información.
• Sistemas de colas: en combinación con los aspectos del punto anterior, se recomienda utilizar sistemas de colas para acumular un alto volumen de solicitudes de procesamiento entrante, sea en forma de solicitudes a demanda o de datos a ingestar. Los proveedores de cloud computing ofrecen sistemas de colas gestionados y privativos, además de compatibilidad con sistemas de colas open source como Apache Kafka.

DIR_03 Integración de datos

OBLIGATORIO El diseño de la arquitectura de datos permitirá distintos modos de integración de datos de los orígenes.

• Ingesta streaming (ELT): el sistema permitirá la ingesta de datos en tiempo real en la plataforma, generalmente a la primera capa de almacenamiento conocida como Data Lake. En esta capa se almacenarán los datos crudos en el mismo formato que se encuentran en el sistema origen. El modelo ELT (Extract-Load-Transform) permite obtener datos en tiempo real de origen para cargarlos en el Data Lake, donde serán almacenados hasta su procesamiento posterior por otros procesos de BigData distribuidos.
• Ingesta batch (ETL): para las cargas con más cantidad de datos, en las que se requiera realizar un procesado en la propia ingesta, se recomienda utilizar sistemas ETL, que procesan los datos conforme son ingestados de origen. Es un proceso más lento que la ingesta a Data Lake, pero permite ofrecer un procesamiento parcial o inicial de los datos ingestados sin esperar a un procesamiento batch, generalmente ejecutado de noche fuera de las horas de uso de la plataforma por los usuarios. Igualmente, los datos procesados parcialmente por este método, pueden ser procesados en modo batch.

DIR_04 Modularidad y flexibilidad

OBLIGATORIO El diseño de la arquitectura de datos será modular y adaptable a cambios en las necesidades de negocio. 

Resulta especialmente conveniente el uso de los servicios gestionados de los sistemas de cloud computing:

• Los nuevos servicios han de poder ser añadidos de manera ágil, sin un alto retardo en el tiempo de implantación en la plataforma.
• Los nuevos servicios deben poder interaccionar entre sí, de modo que los datos ingestados o procesados por un servicio se puedan utilizar en otro servicio.
• Los servicios que por necesidad dejaran de ser utilizados, han de poder ser retirados sin impactar gravemente en la funcionalidad de la plataforma.  
   

DIR_05 Optimización de rendimiento

OBLIGATORIO El diseño de la arquitectura de datos será una plataforma con un rendimiento óptimo de los procesos y que ayude a proporcionar una buena experiencia de usuario.

• Base de datos: los datos estructurados estarán almacenados de modo que su consulta y obtención por las aplicaciones y servicios sea eficiente. Esto se consigue definiendo índices sobre las columnas que lo requieran para suponer una ordenación de los datos y eligiendo el sistema gestor de base datos apropiado según el caso de uso (Oracle, PostgreSQL, etc).
• Almacenamiento de ficheros: los datos no estructurados estarán almacenados en un sistema de directorios que suponga un particionado de los datos, de modo que las consultas no supongan búsquedas sobre el total de los datos.
• Formato de los ficheros: en relación al formato de los ficheros, se recomienda que su estructura sea adecuada para el método de consulta requerida según el caso de uso.  
  Como ejemplo, ante una consulta que requiera realizar una agregación de los datos de una columna, resulta más conveniente y acelera el proceso si los datos se encuentran almacenados en un formato columnar, como ORC o Parquet. En cualquier caso, se eligirá un formato que no afecte negativamente al rendimiento general de la plataforma.
  • Se recomienda utilizar alguno de los siguientes formatos:
    • JSON
    • CSV
    • XML
    • Avro
    • ORC
    • Parquet
    • Delta  
       

Construcción

DIR_06 Data integration

OBLIGATORIO La construcción de los procesos de integración de datos cumplirán los siguientes requisitos:

• Se elaborará un modelo de data flow. Se definirán las reglas sobre cómo los datos se mueven entre los distintos sistemas. Usualmente, para la ingesta de datos de sistemas externos, se define el uso de procesos ETL o pipelines de datos.
• Se indicarán las reglas de mapping de campos entre los distintos sistemas. Los modelos de datos de los orígenes serán, en general, diferentes a los del modelo de datos propio de la plataforma, por lo que es necesario mapear, establecer qué campo de origen se cargará en qué columna de qué tabla del modelo de datos propio. En este proceso se genera un documento de Acuerdo de Interfaz entre los distintos sistemas, que evita confusiones y errores a la hora del desarrollo de las aplicaciones y los procesos.
• Se definirán las reglas de transformación de los datos tras ser ingestados en crudo desde los sistemas origen. Esto conlleva definir cómo se limpiarán los datos no útiles para evitar errores de procesamiento en los procesos, cómo hay que normalizar los datos (número de decimales, formato de fecha, etc) y el modo de agregación de los datos. 

DIR_07 Almacenamiento y acceso a los datos

OBLIGATORIO La construcción de la arquitectura de datos incluirá las reglas de almacenamiento de los datos y del acceso a los mismos a través de consultas.

• Se indicarán las tecnologías de bases de datos y data lake que se utilicen en la plataforma. Debido a que cada herramienta tiene usos distintos, es importante definir las herramientas a utilizar para optimizar el caso de uso concreto para el que se define la funcionalidad requerida.
• Es recomendable indexar las columnas clave para las búsquedas y ordenaciones de las consultas en las tablas de base de datos, así como el particionado de los directorios que contienen los ficheros del data lake. Estas dos medidas optimizan enormemente el tiempo de respuesta de las consultas de los datos, permitiendo en base de datos que la consulta no tenga que recorrer toda la tabla por el índice, y en el data lake, donde puede haber una inmensidad de ficheros, se evita tener que buscar en todos ellos.
• Se explicitará el modo de acceso a los datos para cada caso de uso y perfil, indicando los tipos de consultas SQL a las tablas, así como las vistas a construir que utilizará cada perfil de usuario. Asimismo, se indicarán las APIs a crear para el acceso a los datos, tanto de base de datos como ficheros del data lake. Estas APIs expondrán los endpoints disponibles para interactuar con los distintos datos disponibles en las diferentes herramientas de almacenamiento. 

DIR_08 Lifecycle (ciclo de vida)

OBLIGATORIO La construcción de la arquitectura de datos incluirá las reglas para el ciclo de vida de los datos.

• Se establecerán reglas que definan el tiempo de vida de los datos en la plataforma. Según la naturaleza de los datos, permanecerán en la plataforma de forma indefinida, deberán ser eliminados pasado un plazo, o bien, por necesidades de regulaciones o cumplimiento normativo, no serán eliminados ni alterados en un tiempo determinado (lock/vault).
• Se establecerán reglas de archivo y purgado de los datos. Existen dos tiers de datos: los denominados calientes, o de acceso frecuente, y los denominados fríos, o de acceso infrecuente. Se definirán reglas para el movimiento de los datos entre estos tipos de tiers, ya que los datos en almacenamiento frío repercute en un reducción de coste. Además, existe el almacenamiento de archivo, donde se reduce aún más el coste de los datos que no son accedidos, pero si se necesitan recuperar supone un retardo significativo en su obtención.
• Es recomendable definir reglas de versionado de los datos para mantener múltiples versiones en caso de necesitar un rollback. Al activar el versionado, los datos no son sobrescritos, sino que se crean nuevos datos con una marca de tiempo (timestamp), de modo que los datos antiguos no son borrados y persisten en el sistema. El versionado se puede activar para herramientas de base de datos (e.g. Hbase), donde se debe especificar el número de versiones que se mantendrán de cada dato, como para lagos de datos (e.g. Azure Data Lake Storage), donde se podrán mantener distintas versiones de cada fichero subido.

DIR_09 Metadatos

OBLIGATORIO La construcción de la arquitectura de datos incluirá reglas de uso y gestión de los metadatos de la plataforma.

• Se establecerán reglas de compartición de los datos entre los distintos sistemas y plataformas usando formatos estándar (JSON, XML, CSV). Ante la integración de los datos desde múltiples sistemas origen, es común disponer de ficheros en el data lake con múltiples formatos distintos. Esto dificulta la labor de acceso de los procesos, ya que cada formato de fichero se procesa de un modo distinto con parsers. Se simplifica si se mantiene una capa de datos normalizados, donde los formatos de fichero sean comunes para los diferentes orígenes.
• Es recomendable definir reglas de gestión de datos maestros (MDM), que aseguren la consistencia de los datos en las diferentes capas por las que va avanzando, así como validar que los datos sean precisos o se mantengan fieles a la realidad.
• Es recomendable especificar reglas de creación y gestión de las APIs, qué sistemas interactúan con ellas y los accesos a los datos de las diferentes herramientas de almacenamiento. Debido a que multitud de aplicaciones y procesos pueden acceder a los datos a través de APIs, es recomendable definir un control de acceso y permisos a nivel de aplicaciones para así evitar accesos no deseados desde cierta aplicación a datos restringidos.

Observabilidad

DIR_10 Calidad del dato

OBLIGATORIO Se establecerán controles que aseguren la precisión y la fiabilidad de los datos.

Ante la multitud de datos presentes en las diferentes herramientas, se controlará que los datos sean precisos y fiables. Los datos deben reflejar la realidad que representan, sean datos de mediciones, valores monetarios, o de cualquier otro carácter. Si los datos no son correctos, se generarán informes y mostrarán una realidad errónea a los usuarios que los consumen. 

DIR_11 Validación de los datos

OBLIGATORIO Los datos cumplirán los criterios predefinidos.

Los datos son capturados, almacenados y procesados para satisfacer una necesidad funcional definida por el negocio. Para que se consideren válidos, además de tener un formato determinado y ausencia de errores, cumplirán con las condiciones establecidas basadas en la lógica de negocio.

DIR_12 Integridad de los datos

OBLIGATORIO Los datos mantendrán la consistencia en la plataforma.

Los datos pasan por múltiples capas de ingesta, normalización y procesamiento en la plataforma. En los diferentes pasos, se mantendrá la integridad y la consistencia de los datos. Por ejemplo, un cambio de formato por normalización no puede convertir un dato correcto en incorrecto, ya que se perdería el valor real del dato y, al ser utilizado en informes o mostrado en aplicaciones y portales web, mostraría una realidad errónea a los usuarios.

DIR_13 Monitorización y alertas

RECOMENDADO Se establecerán mecanismos de monitorización y alertas para la detección de errores.

En una plataforma de BigData, con un alto volumen de datos y múltiples herramientas que los tratan y procesan, resulta especialmente recomendable establecer mecanismos de monitorización de accesos, control de errores y umbrales de uso de los recursos hardware. Estos procesos de monitorización permiten definir alertas, de modo que los administradores de la plataforma sean notificados en tiempo real ante un problema que origine un bloqueo en el funcionamiento, permitiendo la intervención inmediata y evitando la mayor cantidad de pérdidas posibles.

DIR_14 Compliance (cumplimiento)

OBLIGATORIO El tratamiento de los datos se realizará asegurando el cumplimiento normativo.

Los datos capturados y tratados en la plataforma, a lo largo del ciclo de vida de los datos en el sistema, cumplirán con las normativas vigentes de aplicación. El más claro ejemplo sería la LOPD, de obligado cumplimiento a nivel europeo, por el que los datos sensibles han de ser cifrados en todo momento en la plataforma para evitar accesos indeseados.

Seguridad

DIR_15 Clasificación de los datos

OBLIGATORIO Se clasificarán los datos en distintos grupos para establecer el grado de seguridad necesario.

Los datos serán clasificados según su naturaleza como datos públicos, privados, confidenciales o restringidos. Cada tipo de datos tiene unos requisitos de seguridad, visibilidad y acceso distinto, de modo que los datos públicos puedan ser vistos y accedidos por todos los usuarios, mientras que los datos confidenciales sólo puedan ser visualizados y accedidos por administradores de la plataforma. Sin establecer esta clasificación, puede haber accesos no deseados a ciertos datos sensibles.

DIR_16 Cifrado

OBLIGATORIO Los datos sensibles se cifrarán en la plataforma.

Los datos sensibles, sujetos a normativas de privacidad, se almacenarán y tratarán cifrados en la plataforma. Esto implica el cifrado en tránsito (activando el cifrado en los conectores o a través del uso de protocolos seguros como HTTPS y SFTP), y el cifrado en reposo cuando estén almacenados, tanto en el data lake como en base de datos. De este modo, se evitarán accesos indebidos a los datos.

DIR_17 Control de acceso

OBLIGATORIO Se establecerá un control de acceso de los usuarios a los datos del sistema.

Los usuarios estarán vinculados a perfiles que definirán sus permisos de acceso a los distintos grupos de datos. Al dar de alta a un nuevo usuario, se le asignarán permisos predeterminados según su perfil, lo que garantiza un control adecuado del acceso a la información. De esta forma, se evita que un nuevo usuario acceda por error a datos confidenciales debido a la falta de restricciones específicas.

DIR_18 Monitorización y auditoría

OBLIGATORIO Se monitorizarán los accesos a los datos y se registrará una auditoría de las actividades de los usuarios.

En una plataforma con gran cantidad de datos y múltiples usuarios que acceden a los mismos, se monitorizarán los accesos de cada usuario a los datos y se registrará la auditoría de los accesos y si son modificados. En base de datos, se pueden incluir columnas adicionales que registren mediante un trigger (disparador) qué usuario y en qué fecha y hora ha realizado una modificación. En el data lake, se pueden incluir metadatos en el fichero de qué usuario y a qué hora lo ha subido a la plataforma o lo ha modificado.

DIR_19 Cumplimiento normativo

OBLIGATORIO Se asegurará el cumplimiento de la normativa vigente que aplique a los datos.

En todo momento, se cumplirán las normativas que apliquen a los datos, involucrando una combinatoria de los distintos puntos anteriores. Se limitará el acceso a datos sensibles, que serán cifrados en todo momento. Además, resulta recomendable auditar los accesos de los usuarios para poder registrar las fechas y horas de modificaciones que afecten a alguna normativa y poder deshacer las modificaciones.

Pruebas

DIR_20 Pruebas de calidad de datos

OBLIGATORIO Se evaluará la calidad de los datos de la plataforma.

Se evaluarán la precisión, integridad, coherencia, validez y puntualidad de los datos, así como de los orígenes de donde se ingestan, las transformaciones y conversiones que se les aplique, y los datos finales almacenados en las bases de datos, listos para su consumo. La calidad debe mantenerse en todo el ciclo de vida de los datos, por lo que se realizarán pruebas que confirmen que los datos mantienen su veracidad y precisión, desde su captura en crudo hasta su almacenamiento final.

DIR_21 Pruebas de seguridad de datos

OBLIGATORIO Se evaluará la seguridad sobre los datos de la plataforma.

Se evaluarán los algoritmos y herramientas de seguridad que se aplican a los datos, tanto cifrado en tránsito como en reposo. Para no ocasionar una violación de ninguna normativa de obligado cumplimiento, los datos sensibles deben ser cifrados desde su captura inicial, pasando por todas las capas de la plataforma hasta su estado final. Esto incluye los procesos que modifican los datos, así como las comunicaciones entre herramientas que intercambian los datos.

DIR_21 Pruebas de rendimiento de datos

RECOMENDADO se recomienda efectuar pruebas de rendimiento sobre la plataforma.

Es recomendable realizar pruebas asociadas a la medición de la velocidad de los procesos y el tiempo total que se requiere para procesar los datos, así como mediciones de la eficiencia en la utilización de recursos hardware. Una plataforma de BigData con un clúster de múltiples nodos que procesan en modo distribuido cuenta con una cantidad de recursos hardware sobre la que se podrán ejecutar un determinado número de procesos, obteniendo un determinado rendimiento. Se recomienda realizar pruebas de rendimiento con una volumetría similar a la esperable en producción para planificar la cantidad de nodos y recursos hardware requeridos.

DIR_22 Pruebas de escalabilidad de datos

RECOMENDADO se efectuarán pruebas de escalabilidad sobre la plataforma.

Se recomienda realizar pruebas de escalabilidad que midan la velocidad de respuesta y adaptación de la plataforma ante variaciones en la volumetría de datos a procesar. Hay que tener en cuenta que los datos no suelen ser constantes; habrá momentos en los que se reciban o se ingesten volúmenes reducidos, y otros en el que se produzcan picos de entrada y el sistema deba reaccionar para evitar pérdida de datos. Se recomienda evaluar la capacidad del sistema para agregar dinámicamente nuevos nodos de procesamiento o aumentar el espacio de almacenamiento disponible, con el fin de evitar pérdidas de datos y que un pico de entrada no sature el sistema.

DIR_23 Pruebas de usabilidad de datos

OBLIGATORIO Se evaluará la usabilidad de los datos en la plataforma.

Se realizarán pruebas de accesibilidad y uso de los datos en plataforma. Los datos deben poder ser accedidos cuando un usuario los requiere, por lo que se comprobará la visibilidad de cada perfil de usuario, los permisos asociados, qué datos puede acceder y las acciones permitidas sobre los datos (lectura o escritura). Además, se evaluará la funcionalidad asociada a los datos, de modo que se compruebe que los datos sirven para el propósito inicial por el que se ingestaron en la plataforma y por el cual se procesan y se almacenan.

Anexo: estándares

Formatos de fichero

JSON (JavaScript Object Notation)

Formato basado en texto fácil de leer y escribir. De uso común en aplicaciones web y APIs, debido a que es un formato serializable, por lo que es un modo sencillo y cómodo de devolver la respuesta de un servicio web ante una petición REST. Permite una definición libre de campos y valores, definiendo entidades y listas. Representa un formato semiestructurado, de modo que no todas las entidades deben contener los mismos campos, por lo que resulta muy versátil y flexible.

• https://json.org/json-es.html

CSV (Comma Separated Values)

Formato simple de texto fácil de entender y usar. Ampliamente utilizado para intercambio de datos pero puede ser ineficiente para datos a gran escala. Supone un formato de campos separados por comas, pero a diferencia del formato JSON, cada registro se compone únicamente de los valores, los cuales deben ser indicados en un posicionamiento concreto. Los valores no indicados deben ser indicados vacíos entre 2 comas, ya que se deben mantener el posicionamiento de las columnas, por lo que resulta poco práctico para casos donde cada registro tiene distinto tipos de campos.

• https://datatracker.ietf.org/doc/html/rfc4180

XML (eXtensible Markup Language)

Formato flexible basado en tags, al igual que HTML, pero que no se debe a unos tags concretos, sino que se pueden definir a conveniencia de los campos necesarios. Resulta cómodo de leer para humanos y permite que sea interpretado por código a través de parsers. Es el formato utilizado para la respuesta de los servicios web SOAP.

• https://www.w3.org/TR/xml/

Parquet

Formato de fichero columnar, de modo que los registros se almacenan por columnas en lugar de por filas como en CSV. Es un formato optimizado para procesamiento en BigData. Eficiente para operaciones que realizan muchas lecturas y es ampliamente utilizado en el mundo de la analítica del dato. También soporta estructuras de datos complejos, permitiendo datos anidados, arrays y mapas. A nivel de almacenamiento, resulta mucho más eficiente que CSV ya que, en lugar de ser texto plano, permite distintos modos de compresión, por lo que requiere menor cantidad de espacio en disco.

• https://parquet.apache.org/docs/

Avro

Formato basado en filas que resulta especialmente eficiente para serialización de datos. Generalmente utilizado para aplicaciones de streaming de datos. Utiliza JSON para la definición del esquema, haciéndolo fácil de leer e interpretar. Incluye marcadores que permite que los ficheros puedan ser divididos en varios de menor tamaño, lo cual resulta ideal para poder paralelizar el procesamiento en un sistema de BigData en modo distribuido entre distintos nodos. Permite estructuras de datos complejos, como arrays y mapas.

• https://avro.apache.org/docs/

ORC (Optimized Row Columnar)

Otro formato columnar como Parquet, pero especialmente optimizado para procesamiento de BigData. Diseñado para cargas de trabajo de Hadoop, obteniendo altos rendimientos en operaciones de lectura y escritura. Eficiente en operaciones con alto volumen de lecturas. También permite la compresión de los datos para ocupar un menor espacio en el almacenamiento. Optimizado para consultas de analítica avanzada.

• https://orc.apache.org/docs/

Delta

Delta Lake es un formato de almacenamiento de datos de código abierto diseñado para construir arquitecturas tipo Lakehouse, que combinan las ventajas de los data lakes y los data warehouses. Basado en archivos Parquet, Delta Lake incorpora un registro de transacciones que permite operaciones con garantías ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), lo que asegura la integridad de los datos incluso en entornos distribuidos. Además, ofrece funcionalidades como la evolución y validación de esquemas, el versionado de datos, y soporte tanto para cargas de trabajo por lotes como en tiempo real, todo ello con semántica de procesamiento exactamente una vez.

Seguridad

HTTPS

Mecanismo de seguridad utilizado para el cifrado de los datos en tránsito a nivel de aplicación con el protocolo HTTP. Añade el protocolo TLS a HTTP para que los datos viajen cifrados entre los puntos inicio y final de la comunicación. Asegura además la integridad de la información, es decir, asegura que los datos no han sido modificados en el tránsito entre cliente y servidor. Permite además validar la autenticidad del servidor al que se está conectando el cliente, ya que el servidor tiene en su posesión un certificado expedido específicamente para la empresa que posee el servidor, por lo que validando la autenticidad del certificado del servidor, se valida que el servidor es el correcto. El cifrado de los datos lleva inherente la protección de los datos sensibles y personales, permitiendo mantener la privacidad de los datos del cliente en la transmisión.

• https://http.dev/https
• https://www.rfc-editor.org/rfc/rfc2818

Claves asimétricas (RSA)

Las claves asimétricas suponen un par de claves conocidas como clave pública y clave privada. La primera es publicada para que pueda ser conocida por el público, mientras que la segunda, como su nombre indica, debe ser mantenida de modo privado y que sólo su propietario sea conocedor de la clave. El funcionamiento de este par de claves supone que los datos pueden ser cifrados con una de las claves y descifrados con la otra clave. Es más, los datos cifrados con una de las claves sólo pueden ser descifrados con la otra clave del par. Esto abre una doble funcionalidad al uso de las claves asimétricas, permitiendo la autenticidad y la integridad de la información intercambiada en una transmisión. Enviar datos cifrando con la clave pública del usuario destino asegura que sólo dicho usuario podrá descifrar los datos, asegurando la integridad de la información ya que nadie más podrá acceder al contenido descifrado. Enviar datos cifrados con la clave privada del usuario origen asegura al usuario destino que la información proviene indudablemente del usuario origen correcto, ya que si es capaz de descifrar los datos con su clave pública, es que inevitablemente fueron cifrados con su correspondiente clave privada, la cual sólo está en su posesión, asegurando la autenticidad del usuarios origen. La combinatoria de ambos cifrados origina un escenario seguro completo.

• https://datatracker.ietf.org/doc/html/rfc8017

Claves simétricas (AES)

Las claves simétricas suponen un tipo de clave que son utilizadas para cifrar y descifrar los datos utilizando la misma clave. Esta clave tiene que mantenerse en secreto en todo momento, y que no pueda ser conocida por usuarios que no deben tener acceso a los datos. Soporta longitud de 128, 192 y 256 bits, siendo la última la más segura. Es conocido por su alta velocidad y eficiencia, pudiendo ser utilizado para proteger los datos en tránsito (la misma clave debe ser conocida por ambos usuarios), o para cifrar los datos en reposo en un Data Lake o una base de datos. Es resistente a diferentes tipos de ataque, incluidos la fuerza bruta y el criptoanálisis diferencial.

• https://web.archive.org/web/20150407153905/http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 

HASH (SHA2, SHA3)

Aparte del cifrado de los datos sensibles y personales, las funciones HASH son utilizadas principalmente en seguridad para calcular un resumen de ciertos datos que no se desea que puedan ser revertidos, como puede ser el caso de las contraseñas de los usuarios. Una contraseña almacenada en una columna de una tabla de una base de datos no debe poder ser accedida ni por un administrador de la plataforma, por lo que el uso de cifrados para las contraseñas no resulta efectivo. El escenario ideal es no guardar la contraseña, sino un resumen de la misma. Ante un inicio de sesión de un usuario, la aplicación calculará el mismo resumen de la contraseña introducida por el usuario y comprobará si el valor coincide con el almacenado en base de datos.

• https://www.rfc-editor.org/rfc/rfc6234